Network devices, such as routers, are extensively tested to ensure that erroneous transmissions and fatal errors are minimized. A variety of test devices are available on the marketplace, including the ROUTER TESTER from AGILENT TECHNOLOGIES, assignee of the present application. Such test devices typically monitor the routers response to a variety of simulated input.
The process of routing can be quickly summarized as a node finding the path to every possible destination. Routing is present in everything from layer 1 (the physical layer) on up. The routing that most people are familiar with, however, occurs at layer 3 (the network layer) and as such, only layer 3 (and more specifically) Internet Protocol (IP) routing will be referenced herein. Routers use tables to determine where to forward packets. Updating these tables is a function performed by routing protocols. Each router is responsive to one or more protocols.
Protocols for exchanging routing information connect multiple routers around the world to provide them with a common view of the network through their heterogeneous, though generally consistent routing tables. Routing tables store all information necessary for the router to reach every destination on the network irrespective of size. There are a wide variety of routing protocols used to contribute to the routing tables across a network. Protocols such as BGP, OSPF, RIP and ISIS help to convey a correct and coherent picture of the network to all routers on the network.
Known router testers simulate network traffic using specifically created “test packets” of data that are typical of the live data present on the network. These test packets are transmitted to the network device over a network under test. Parameters tested by traffic simulator systems (including ROUTER TESTER) include routing verification, achievement of Quality of Service (QoS) levels under load, and correct inter-working with other devices. Many of these so-called “packet blasters” also test the ability of the network device to adhere to protocols by formulating and transmitting messages in accordance with the protocols.
FIG. 1 is a block diagram of a traffic simulator test system 100. More particularly, the traffic simulator test system 100 is a general representation of ROUTER TESTER, offered by AGILENT TECHNOLOGIES. ROUTER TESTER is but one example of a router test system and in particular is advertised as a multi-port traffic generation, protocol emulation, and analysis test system for verifying the performance of enterprise, metro/edge, core routing and optical networking devices. The system generally comprises a plurality of protocol emulation cards 102n connected to a system under test, in this case a router 104. Each of the protocol emulation cards 102n generally comprises a processor with associated memory and I/O. The protocol emulation cards 102n are controlled by a computer 106, such as a PC running a WINDOWS environment. The computer 106 is responsive to an interface 108, such as a graphical user interface.
The test packets produced by the protocol emulation cards 102n are built according to the rules and interpretations of communications protocols, such as those defined by the many standards bodies in the industry. There are many communications protocols in use and new protocols continue to be developed. Typically, new protocols are initially developed by equipment manufacturers and are proprietary in nature. Often, the protocols are subsequently adopted by standards bodies for widespread implementation in industry.
The current software architecture associated with traffic simulator test systems requires hard-coding all parts of the protocol emulation solution including the graphical user interface, scripting API, configuration and control components, and the protocol state machine itself. The hard coding required for each protocol has resulted in the use of an enormous amount of human talent to create the large body of code. Much of this code is dedicated to interfacing the computer 106 with each new protocol emulation card 102n. 
The traditional approach to interfacing the computer 106 with each new protocol emulation card 102n requires methods and associated parameters to be known at the time the interface is written and hard coded in an interface description language (IDL). Under this paradigm, new methods and parameters are continually being created each time new protocol emulations are written or old protocols are extended. This has resulted in a vast API (application programming interface) containing many hundreds of methods and parameters, resulting in a body of code that is expensive to maintain. Further, the known approaches result in the API being replicated at several different layers, thereby compounding the problems. Thus, each change to the API (no matter how small) requires the updating of a significant amount of code and different levels within the system. One side effect of this approach is that a unique GUI must be generated for each protocol and each update thereof. As with the API, as the number of protocols grow, so do the required GUI implementations.
Efforts are now being made to design generic systems that alleviate some of the foregoing problems. One example is described in co-pending U.S. patent application Ser. No. 10/266,507, Publication No.: U.S. 20040068681 A1, entitled: Building packets of data. U.S. 20040068681 A1, incorporated herein by reference, uses an external XML protocol description to drive a generic PDU encode/decode engine. A next step is to build a generic interface to the protocol emulators that do not require new code or hard coded interfaces changes for each new emulator or change thereto.
One known approach to this problem is the use of an Interface Definition Language (IDL), such as DCOM or CORBA. However, IDLs have proven unsuitable, as they require all details of each interface to be known at compile time. Another option is the use of ASN.1—a language for defining any data structure. Known ASN.1 compilers generate interface code for encoding and decoding such structures. However, like IDL's, ASN.1 is a compile time solution requiring specifically written code for each interface. Another option is using one of the available XML data models, such as DOM (Document Object Model). However, XML data is transmitted as text files which are an inefficient use of bandwidth. Further, XML data usually requires very processor intensive computations along with time consuming parsing. Further, navigation of a DOM structure is slow and does not naturally represent tabular data (which is prevalent in protocol emulator interfaces).
Accordingly, the present inventors have recognized a need for new interface mechanism capable of representing all commands, configuration data, and output from a protocol emulation. Further, such a mechanism should be equally adroit at hierarchical data as with tabular data.
In the description contained hereinafter, the use of a lowercase “n” adjacent to an element identifier denotes a non-specific instance of the element rather than a specific element as shown in the figures or discussed in the specification with a non-italicized letter adjacent to the element number.